meeting date: 10 may 2005
attending:	Todd Westerhoff, Arpad Muranyi, Donald Telian, Mike LaBonte, Barry Katz
(minutes not totally in chronological order)

Summary of last meeting: We like the idea of using VerilogA as a basis language, and we left off last time wondering what the element set would be.

Some discussion related to HSPICE:
- Should we have transistors? Which ones? Legal problems? 
- We should agree on an advanced SPICE language (Donald).
  This is separate from the VerilogA idea.
- Can we add HSPICE as a language choice in IBIS? Only with permission.
  How does Silvaco do it? Not much support for this idea.
- Can instantiation be done using HSPICE syntax?
  Connectivity is the simplest part, so why not do it in VerilogA?
- Having accepted VerilogA, we don't care much about SPICE languages.
  But if a company is willing to allow the use of their SPICE element
  usage details, we could model our core VerilogA element library after
  that.
  - Use existing parameter keyword values, expression syntax, etc.
  - HSPICE would be a good base.
The consensus is that VerilogA language would be used, to be compliant with the existing IBIS spec. However, it sounds like compatibility of call parameter values, which may contain non-VerilogA expression syntax, should be discussed in another call.

AR: Todd will ask Synopsys about restrictions on use of HSPICE syntax.

Todd proposed some terminology:
- building blocks		Low level elements that can be written in VerilogA.
                        Mappable to other simulators.
				This is the low level library.
- templates			Circuits of building blocks wired together.
				This is the higher level library.
- black box templates	Templates can be hard-coded in a simulator-specific
				language as long as the behavior matches the
				associated VerilogA template.
				(did I get this right?)

Some discussion of libraries and version numbers:
- Need to have version numbers for building block library.
- Need a public depository to make it easy to get the latest version.
- We need both low level and high level modules.
  - Separate libraries for these.
- The initial building block list must be robust.

We went over Donald's slides on high level modules:
- features that HSPICE can't handle:
  - buffers:
    - c_comp on/off
    - dynamic scaling
  - time controlled sources
  - equations:
    - prev(x)
      - used for self-calibrating output and pass-through receiver.
    - 1st deriv (a few elements can do this)
    - if/else?
- Need to establish the equation language
- We don't want to shoot for least common denominator of what
  simulators can do.
  - If Mentor, Cadence and Synopsys can do it, we go with it.
We probably need to have proposed equation syntax in front of us for further discussion. Also need to revisit c_comp and dynamic scaling.

Some discussion of what the set of I & V source building blocks should be:
- SPICE defines E, F, G, H, V, I
- But isource and vsource elements with equations could replace them.
  - Additional advantage of allowing multiple control inputs
  - Time control sources can be implemented using parameters on these.
We need a specific proposal to discuss.

AR: Mike will email starter building block list with terminals and params

Donald leaves Cadence May 31, Ken Willis will take his place in these meetings.

We will prepare a presentation for DAC:
- Arpad will take the lead on the presentation, Todd assisting.
- After the DAC presentation simulator vendors can have their say.
- Todd will attend IBIS summit too.